\section{Related Work}\label{sec:related}
\xxx[br]{Need to add to Mementos and QuickRecall that they do not correctly handle nv-external inconsistency or nv-internal inconsistency}
\sys builds conceptually on Mementos~\cite{mementos}, a system designed to save
state to onboard flash at compiler-selected intervals on failure-prone
energy-harvesting embedded systems.  Mementos heuristically places calls to a
checkpointing function at code points that are likely to represent transition
points in the computation, such as loop backedges and function returns.  The key
difference between \sys and Mementos is that \sys, rather than using heuristics
to drive checkpointing of entire system state, allows programmers the freedom to
define the appropriate transition points and express corresponding recovery
steps.

\sys's approach is distinct from run-time mechanisms that depend on the
idempotence of tasks for safe, robust execution.  Idempotence guarantees are an
effective way to ensure that interrupts do not permanently interfere with
certain application state---any idempotent task can, by definition, be
reexecuted safely---but idempotence is inappropriate when the operating
conditions invalidate the inputs.
%
\sys's recovery semantics enable reasoning about changed state during recovery,
defending against this problem.

The authors of QuickRecall observe that FRAM storage is orders of magnitude
faster and more durable than flash storage~\cite{quickrecall}, the same reason
we selected the Wolverine chip for prototyping \sys.  They find that
checkpointing to FRAM instead of flash enables a simpler design than that of
Mementos.  In contrast, \sys extends the abstract idea of state retention across
power failures to the programming-language level, making it newly feasible for
programmers to provide explicit recovery semantics for their programs.

Mnemosyne is a programming interface for storage and heap allocation on
persistent memory.  It provides \lil{pstatic} and \lil{persistent} keywords for
variable declarations and run-time primitives such as \lil{pmap} (\lil{mmap} for
persistent regions) to interact with persistent memory via a block-device
interface.  To provide consistency across power failures, Mnemosyne offers
fences for strict memory ordering and transaction semantics built atop hardware
transactional memory.
% mnemosyne not portable to embedded domain -- but don't want to pitch \sys as
% just a port of mnemosyne...
\sys, in contrast, is designed to enable OS-less embedded devices to work
smoothly despite power interruptions, and must therefore operate without an
operating system or hardware transactional memory.
% power failures common in our case
In \sys, power interruptions are a constant presence rather than a rare event,
resulting in even finer-grained atomicity problems than Mnemosyne faces.
% storage vs. main memory
\sys also focuses on problems inherent in persistent \emph{main memory} rather
than separate storage.  It therefore must provide a more general programming
interface that is not based on explicit use of persistence primitives.
%%% but did mnemosyne solve the problem we're proposing???  answer must be no

Saving state on machines that are \emph{not} fundamentally failure prone is the
focus of Whole-System Persistence (WSP)~\cite{narayanan:wsp}, which uses
capacitance-backed volatile memory to provide ``flush-on-fail'' semantics to an
entire operating system mostly transparently.
